>They mention that NFS and Sun RPC in general are >vulnerable to the sequence number attack. It is true that >nfs and other rpc's do rely on IP address for authentication >but I dont see how they are vulnerable to an attack. You >need to see the reply in order to get a filehandle in order >to do anything with nfs. If you can guess the filehandle, you don't need the reply packet. NFS' filehandles aren't really unguessable on some machines; for example, an unpatched SunOS 4.1.2 machine doesn't really make it difficult enough. All the same, I think many of the NFS attacks rely on being able to guess a valid directory fh, lookup .., cd .. until it hits the root -- not being able to read the reply packets would make it impossible to read the values for ..'s fh. Also, using rsh to do 'echo "+ +" > /.rhosts' would be a hell of a lot easier... ;) Here's some relevant stuff I have saved from bugtraq; you might also want to read the source for nfsbug for more details. --j. %Date: Tue, 19 Apr 1994 17:21:12 +0200 (METDST) %To: bugtraq@crimelab.com %From: Stefano Taino <taino@dsi.unimi.it> %Subject: Re: More on NFS hacking As near as I can tell, this is Sun's definition of the "opaque" file handle: long device; /* device of FS on server. */ long fs_type; /* file system type of FS on server. */ long fsid; /* fsid of file being specified. */ long fid; /* fileid " " " " */ long gen; /* generation " " " " */ long exp_fsid; /* fsid of export point on server. */ long exp_fid; /* fileid " " " " " */ long exp_gen; /* fileid " " " " " */ For the file handle of an export point: fsid == exp_fsid && fid == exp_fid && gen == exp_gen if the export point happens to be at the root of a UNIX file system, then both fid and exp_fid will be 2, since UNIX traditionally uses 2 for the root of its file systems. But if a directory below the root of a file system is exported, then exp_fid will contain whatever value that is. Here are some sample file handles from a Sun server running SunOS 4.1.1. With "/home" (root of a file system) as the export point, the fh of the export point is: 1799 1 655360 2 1155997163 655360 2 1155997163 With "/home/eng" as the export point, the fh of the export point was: 1799 1 655360 26276 1648502143 655360 26276 1648502143 Notice that there isn't a 2 anywhere in the file handle. When I mounted "/home/eng" when the export point was "/home", the fh of the mount point was: 1799 1 655360 2 1155997163 655360 2 1155997163 Notice that the {fsid,fid,gen} triple here matches that triple from the second case, while the {exp_fsid,exp_fid,exp_gen} triple matches that triple from the first case. This is because the first triple represents that actual file the fh is fore, and the second triple represents the export point of that fh. -- Stefano. %From: jsz@ramon.bgu.ac.il (jsz) %Subject: Re: RPC protocol problem? %Date: Thu, 25 Aug 94 3:46:00 IDT %Cc: bugtraq@crimelab.com > > "In the previous message, Doug Davis said..." > > > > The real question is one of; how to beat vendors into fixing the > > problems reported by it.. (grumble grumble)... > > > > Or failing that, has anybody devised a way to: > > A: use LD_PRELOAD to replace the random() (or srandom()) or whatever function > fsirand calls with one that ignores the passed init seed, and produces its > own, to make it work right...? > or > B: Make available sources for a replacement fsirand that will work on SunOS > and other affected OS's that one can build and run. There has been a patch for it, for over 2 years. 1063470 Non-random file handles can be guessed, leading to security hole. NFS jumbo patch fixes it. > or > C: I resorted to letting the PIDs get way up there, say over 10,000 then > kicked the system down to single-user, did a umount -a, and ran it on all > the filesystems (except /, and /usr, of course). Making sure it wasn't > shut down and rebooted, the PIDs just continue from what they were when > it was up in multi-user. > > So, all I get in nfsbug output is the UID bug (which goes away if I don't > export as root, but sometimes that is needed). I wonder if anybody > has put together the affected module from non-restricted sources, > so people can fix it? I know that Suns NFS jumbo patch doesn't > affect the UID bug, as it is still there. I have no idea if it > fixes the fsirand prolbem or not... Yes, it does fix the fsirand problem. UID bug? you mean the uid_t bug, uid/gid values are supposed to be 32 bits wide, while SunOS's uid_t is 16, it affects all OS's that have uid_t == 16 bits, eg IRIX, etc have this problem too, there is a patch for it, as well. 1095935 NFS server in which a client presenting a 32-bit uid in which the 16 low-order bits are 0 gets interpreted as root on the server.